Yesterday: 18 failed tests
Today: 10 failed tests 😅

And this is only unit tests. Still pending the e2e tests 😵

Unit tests fixed locally. Now figure out how to fix these conflicts 😰

Rebased, fixed conflicts, but couldn't figure out how to update the tree/gscan Vuex modules 💫 😵

Codecov Report

Merging #802 (2513af3) into master (ffb70c6) will decrease coverage by 0.70%.
The diff coverage is 85.18%.

@@            Coverage Diff             @@
##           master     #802      +/-   ##
==========================================
- Coverage   91.00%   90.29%   -0.71%     
==========================================
  Files          87       90       +3     
  Lines        1700     1773      +73     
  Branches      105      106       +1     
==========================================
+ Hits         1547     1601      +54     
- Misses        123      141      +18     
- Partials       30       31       +1     

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ffb70c6...2513af3. Read the comment docs.

Finally unit tests passing! 🙏 (also had to fix git conflicts, lint, then docs, so not only unit tests 😅 )

Just one e2e test failing now, almost there...

One brittle test. When we visit URL's, and then click on buttons, it's taking too long to load the subscription (sometimes) and then the test is failing as it did for firefox ☝️ will investigate tomorrow.

The test was waiting for c-tree. But that's added too soon. I could chain methods (.then(() => { blabal.then(() => {...}}) }) but it gets a bit harder to read.

But there was an easier way to tell Cypress to wait for the tree to show. Just wait on c-task class instead. It only ever appears in the UI after the first Task component was added to the DOM 🎉 tests fixed, less brittle. Ready for review.

This might take a while to review, so @AaronDCole will probably inherit it. But at least it's not brittle, and doesn't have git conflicts. The best way to understand this PR is to understand how the Tree component & view work. This is basically the same as GScan on master, but instead of computed re-creating the GScan data structure/variable with every change, we build the Vuex gscan.gscan variable incrementally, applying deltas as received.

🖖

@oliver-sanders I'm guessing this will be closed now?

I think we'll have to work out how to pull the propagate states logic out onto the redesigned store. I think we could probably put that logic into a computed property on the GScan component?

Since the data store refactor we now have a universal tree containing both the GScan (workflow) and Tree (task) parts. This is updated incrementally using the global-callback.

So the workflow tree is being computed incrementally, but GScan is still using a computed property rather than iterating over this directly because of sorting and filtering.

In order to sort/filter incrementally it is still necessary to write a callback for GScan using the data from the lookup as done on this branch. The callbacks here are still valid, lookup has become $index but otherwise it's basically the same. Ideally we would avoid callbacks as these duplicate data processing and require loads of maintenance because they are bespoke to each view.

Because GScan is the only component (so far) that is worried about workflow iteration order, we could consider changing the sort order of the central store to what GScan expects, then use v-if to handle filtering. That would cut out the computed property completely.

Alternatively, we could consider maintaining a separate index in the central store just for GScan (e.g. $gscan).